High-level languages for low-level programming

ions Abstractions have a cost. File systems and network protocols are generic and not tailored to one particular application. We cannot expect an abstraction to be optimal with respect to every application that uses it. Similarly on the PL side one cannot expect a general purpose PL to provide the exact abstractions needed for one particular application. These abstractions too have a cost: they reduce performances or impose a certain style to the programmers. This cost is often paid whether the abstractions are actually used or not (e.g. tail-calls are not optimised in Python even when debugging functionalities are not used). However, abstractions are useful. Chief among their strengths is genericity. It makes code portable (across systems that ship the required set of abstractions) and coders more efficient (by allowing them to apply the same technologies to different projects). It is generally admitted that the portability of C is one of the reasons Unix got so much traction—even though switching to (what was at the time considered) a high-level PL was controversial. Increasingly numerous and higher abstractions are necessary to effectively build ever-more-complex systems. Abstraction clash Currently, low-level code (i.e. code that runs in the lower layers of system abstractions, code that runs close to the metal; e.g. code for file systems, network stacks, process schedulers), is written in low-level PLs, in one low-level PL in particular: C1,2. The reason C is a good PL for such tasks is twofold: it offers various abstractions (e.g. functions, unions, structs), and these abstractions are provided in a way that does not impede fine-grain control over the dynamic behaviour of programs3 (e.g. the dynamic layout of unions and structs in C are simple and very easy to predict whereas ADT in Haskell or ML are not).ion clash Currently, low-level code (i.e. code that runs in the lower layers of system abstractions, code that runs close to the metal; e.g. code for file systems, network stacks, process schedulers), is written in low-level PLs, in one low-level PL in particular: C1,2. The reason C is a good PL for such tasks is twofold: it offers various abstractions (e.g. functions, unions, structs), and these abstractions are provided in a way that does not impede fine-grain control over the dynamic behaviour of programs3 (e.g. the dynamic layout of unions and structs in C are simple and very easy to predict whereas ADT in Haskell or ML are not). In low-level code, it is necessary to take care of some details. In fact, code that takes care of execution-time details is by definition low-level code (i.e. code that does not rely on abstractions). It is important to note that low-level code is necessary: in order to provide an abstraction for a part of the system, a programmer needs to deal with all the details of this part of the system manually. 1C was once considered high-level, it is now on the very bottom of the PL heap just atop assembly. 2There are projects of network stacks in higher-level PLs (e.g. FoxNet [1], Mirage [2]); however, these are not widely deployed, use some C internally, and suffer from performance issues. 3For additional details, see “the costs of abstraction” talk on http://suckless.org/conference.